Was wird geprüft?

Wenn Webanwendungen Statusmeldungen erzeugen, etwa wenn ein Produkt in einen digitalen Warenkorb gelegt wurde, ein Formular beim Abschicken eine Fehlermeldung oder eine Bestätigungsmeldung erzeugt, sollen visuell eingeblendete Statusmeldungen über geeignete Rollen oder Eigenschaften ausgezeichnet werden und damit programmatisch, also auch für nicht-visuelle Nutzer, ermittelbar sein.

Beispiele für Statusmeldungen:

  • Ware wurde im Shop dem Warenkorb hinzugefügt

  • 3 Bücher der Merkliste hinzugefügt

  • Formular erfolgreich abgeschickt (Erfolgsmeldung)

  • 5 Suchergebnisse (etwa nach Filterung der Ergebnisse)

  • 3 Fehler im Formular (bei clientseitiger Prüfung ohne Neuladen der Seite)

  • Punktestand geändert

  • Seite wird geladen (bei visueller Ladeanzeige/Fortschrittsbalken)

Warum wird das geprüft?

In vielen Nutzungskontexten erhalten sehende Benutzer von Webanwendungen Statusmeldungen (einige von ihnen vorübergehend), die Rückmeldungen über das Ergebnis von Interaktionen (z. B. die Zahl der beim Filtern einer Suchergebnisliste zurückgegebenen Einträge) oder den Erfolg oder Misserfolg von Transaktionen geben. Diese Meldungen sind ebenso wichtig für nicht-visuelle Nutzer und sollten für assistive Technologien verfügbar sein, damit die Nutzer auf sie aufmerksam werden, ohne ihren aktuellen Fokus oder Standpunkt ändern zu müssen.

Wie wird geprüft?

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Webinhalte Statusmeldungen generieren, die nicht den Fokus erhalten. Er ist nicht anwendbar, wenn Meldungen im Zusammenhang mit Kontextänderungen erscheinen, zum Beispiel, wenn nach dem Abschicken eines Formulars die Seite neu lädt und dann vor dem Formular eine Fehlermeldung erscheint.

2. Prüfung

  1. Screenreader NVDA im Firefox-Browser aktivieren.

  2. Eingaben vornehmen, die zur Generierung von Statusmeldungen führen. Sofern das Angebot von sich aus Statusmeldungen generiert, etwa bei aktualisierten Inhalten, diese Meldungen abwarten.

  3. Prüfen, ob Statusmeldungen beim Erscheinen vom Screenreader ausgegeben werden.

3. Hinweise

Nicht als Statusmeldung gelten:

  • Fehlermeldung über Dialog (Kontextänderung durch Fokusumsetzung)

  • Die Hinzufügung von Bedienelementen, wie z. B. zusätzliche Formularelelemente

Zum Test mittels Screenreader: Ob die Statusmeldung tatsächlich vom Screenreader ausgegeben wird, kann abhängig von genutztem Browser und Screenreader unterschiedlich ausfallen. Der Erfolg kann davon abhängen, ob die Statusmeldung in ein bereits bestehendes Element eingefügt wird oder ob eine kurze Zeitverzögerung vor der Generierung der Meldung definiert worden ist.

Das HTML-Element der Statusmeldung muss mit den zugehörigen Rollen/Eigenschaften vorhanden sein, bevor die Statusnachricht erzeugt wird, also in das HTML-Element eingefügt wird. Das Erzeugen des HTML-Elements und der eingefügten Statusnachricht sind zwei getrennte Aktionen.

ARIA-Attribute wie aria-atomic, aria-busy, aria-relevant müssen auf Statusmeldungen in der Regel nicht eingesetzt werden. Die Angabe der geeigneten Rolle definiert passende Werte für diese Attribute bereits implizit.

4. Bewertung

Erfüllt

  • Alle Statusmeldungen sind richtig ausgezeichnet und damit programmatisch verfügbar.

Einordnung des Prüfschritts

Einordnung des Prüfschritts nach WCAG 2.1

Guideline

Success criterion

Techniques

Situation A: If a status message advises on the success or results of an action, or the state of an application:

Situation B: If a status message conveys a suggestion, or a warning on the existence of an error:

Situation C: If a status message conveys information on the progress of a process:

Failures

Quellen